Profile picture

[AWS] S3 이관하기

Amaranth2023년 11월 25일

글을 쓴 이유

이번에 우테코 5기 과정이 종료되면서, 커디 프로젝트를 배포하고 있던 서버 인프라를 우테코에 반환해야 했습니다. 저희 팀은 커디를 지속적으로 서비스할 의향이 있었기 때문에, 팀 AWS 계정을 만들어 서버를 이관하기로 결정했습니다.

서버 이관이라는 작업이 흔히 경험할 수 없는 일이기 때문에, 이 과정을 기록하고 공유하기 위해 이 글을 작성하게 되었습니다.

어떻게 이관할까

저희가 기존에 구축했던 인프라 구조는 위와 같았습니다. EC2 서버 세 대를 각각 프로덕션 서버, 개발 서버, 프로덕션 서버의 DB로 이용하고 있었고, S3의 prod, dev 폴더에 프로덕션 서버, 개발 서버의 이미지를 저장해두고 있었습니다. 이런 인프라가 만들어진 것은 우테코의 서버 제공 정책 때문이었습니다.(물론 필요한 경우 추가적인 자원을 직접 요청할 수도 있었습니다.)

  • EC2: 팀 당 최대 4대까지 제공
  • S3: private 권한, 하나의 버킷을 모든 팀이 공유하는 형식.
  • CloudFront: 팀 당 1대 제공

이 인프라를 그대로 유지한 채 이관을 하는 것은 비용적으로 부담이 될 것이라 생각해, AWS 프리 티어 정책을 조사하였습니다. 프리티어 정책 상 EC2 한 대와 일정 한도 내에서 RDS, S3를 1년 동안 무료로 이용할 수 있었습니다. 그래서 저희는 팀 AWS 계정을 실 서버용, 개발 서버용으로 2개를 만들고 각각 EC2는 API 서버, RDS는 DB, S3는 이미지 저장소로 활용하여 인프라를 구축하기로 하였습니다.

논의 과정에서 CloudFront는 제외되었습니다. 이전 인프라에서 CloudFront를 이용했던 것은 순전히 우테코의 서버 제공 정책으로 인해 외부에서 S3 내 이미지 파일을 조회할 수 있는 방법이 CloudFront를 경유하는 것 외엔 없었기 때문입니다. 지금은 저희가 프리티어 한도 내에서 자유롭게 인프라를 구축할 수 있는 상황이니, S3의 조회 권한을 public으로 열어두면 현 시점에서 굳이 'CloudFront를 사용해야 할 이유'가 없었습니다. 물론, S3를 pubic으로 열어둔 것에 추후 문제가 발견되거나 CloudFront로 인한 성능 개선의 여지가 보일 경우 다시 한 번 팀 내 논의를 거쳐 CloudFront를 도입할 계획입니다. 일단은 빠르게 서버를 이관하는데 집중하기로 했습니다.

S3 이관하기

4명의 백엔드 인원을 두 팀으로 나누어 각각 실 서버, 개발 서버 이관을 맡았습니다. 저는 개발 서버 이관을 맡았고, 그 중에서도 S3 셋팅 및 데이터 이관을 주도했습니다.

처음 S3를 이관하는 방법에 대해 고민했을 때 가장 먼저 생각 났던 건 'AWS 콘솔에서 S3의 폴더 내 파일을 한 번에 압축해서 가져올 수는 없나?'였습니다. 찾아보니 그런 방법은 제공하고 있지 않았습니다...🥲 좀 더 찾아보니 AWS 계정 간 S3 버킷 내 데이터를 이관하는 방법이 있었습니다. 하지만 이 방법은 원본 S3의 버킷 정책을 건드려야 했었고, 우테코에서 이를 권장하지 않았기에 다른 방법을 찾아야 했습니다.

AWS CLI

그러던 중 AWS CLI라는 것을 알게 되었습니다. AWS CLI는 서버(EC2) 내에 설치하여 터미널에서 쉘 커맨드로 AWS 서비스와 상호작용할 수 있는 도구입니다. AWS CLI를 사용하면 EC2에서 직접 S3에 접근해 모든 이미지들을 한 번에 업로드/다운로드할 수 있습니다. 다행히도 우테코에서 제공받은 EC2가 S3에 직접 접근할 수 있도록 권한 설정이 되어 있었기 때문에, 저는 이를 활용해 S3의 데이터를 이관하기로 결정하였습니다.

이관을 해보자

전체 과정을 요약하면 다음과 같습니다.

  1. 우테코 S3의 이미지들을 우테코 EC2로 다운로드
  2. 우테코 EC2의 이미지들을 로컬 저장소(mac)로 복사
  3. 로컬 저장소(mac)의 이미지들을 커디 EC2로 복사
  4. 커디 EC2의 이미지들을 커디 S3에 업로드

1. 우테코 S3의 이미지들을 우테코 EC2로 다운로드

먼저, 우테코 EC2에 접속한 뒤 awscli를 설치해줍니다.

sudo apt install awscli

그리고 다음 명령어를 통해 우테코 S3의 dev/ 경로에 있는 이미지들을 우테코 EC2의 s3 폴더에 다운로드합니다.

aws s3 cp --recursive s3://2023-team-project/2023-kerdy/dev/ ./s3

2. 우테코 EC2의 이미지들을 로컬 저장소(mac)로 복사

여기서는 scp 명령어를 사용합니다. 이를 위해 로컬로 전송할 폴더(s3)에 권한을 부여해줍니다.

chmod -R 777 s3

로컬 터미널로 돌아와 scp 명령어로 우테코 EC2의 파일을 가져옵니다.

scp -i [pem파일경로] -r [ec2-user계정명]@[ec2 instance의 public DNS]:~/[서버 폴더 경로] [로컬 폴더 경로]

ex)

scp -i /Users/amaranth/Documents/pem/key-kerdy.pem -r ubuntu@ec2-xx-xx-xx-xx.ap-northeast-2.compute.amazonaws.com:/home/ubuntu/s3 /Users/amaranth/Documents

3. 로컬 저장소(mac)의 이미지들을 커디 EC2로 복사

이제 로컬로 가져온 s3 이미지들을 다시 scp 명령어를 사용해 커디 EC2에 전송합니다.

scp -i [pem파일경로] -r [로컬 폴더 경로] [ec2-user계정명]@[ec2 instance의 public DNS]:~/[서버 폴더 경로]

ex)

scp -i /Users/amaranth/Documents/pem/kerdy-dev-key.pem -r /Users/amaranth/Documents/s3 ubuntu@ec2-xx-xx-xx-xx.ap-northeast-2.compute.amazonaws.com:/home/ubuntu

4. 커디 EC2의 이미지들을 커디 S3에 업로드

이제 커디 EC2에 접속하여 awscli를 설치해줍니다.

sudo apt install awscli

S3를 Public Access으로 열어두긴 했지만, 버킷 정책으로 이미지 조회(GetObject) 권한만 열어주었기 때문에 외부에서 버킷 내 데이터를 변경하는 작업은 아직 할 수 없습니다.

커디 EC2가 S3에 접근할 수 있도록 권한을 주는 방법에는 크게 세 가지가 있습니다.

  1. VPC 콘솔에서 Endpoint를 생성하고 버킷 정책에 해당 Endpoint에 대한 접근 권한을 추가해준다.
  2. S3에 대한 접근 권한을 가진 IAM 역할을 만들고 EC2에 부여한다.
  3. S3에 대한 접근 권한을 가진 IAM 사용자를 만들고, 스프링 애플리케이션이 해당 사용자의 액세스키를 통해 로그인하도록 한다.

여기서 기존에 권한을 부여했던 방식은 2번이었고, 다른 방식을 선택할 경우 애플리케이션 설정 파일을 건드려야 했기 때문에 빠른 작업을 위해 2번의 방법을 사용하기로 했습니다.

잠시 aws 콘솔로 들어갑니다.

EC2 인스턴스 화면으로 이동해, 작업>보안>IAM 역할 수정으로 들어갑니다.

여기서 새 IAM 역할 생성을 클릭합니다.

역할 생성을 클릭합니다.

해당 역할이 부여될 대상은 EC2이므로, 사용 사례에서 EC2를 선택해줍니다.

권한 정책으로 AmazonS3FullAccess를 선택합니다.

이렇게 역할을 생성하고, 다시 EC2의 IAM 역할 수정 화면으로 돌아와서 조금 전 생성한 역할을 설정해줍니다.

이렇게 하고 IAM 역할 업데이트를 클릭하면, 우리의 EC2가 드디어 S3에 접근할 권한을 얻게 됩니다.

권한이 제대로 동작하는지 확인하기 위해 다음 명령어로 S3 버킷을 조회해보면

aws s3 ls s3://kerdy-dev

이렇게 버킷에 저장된 파일들을 확인 할 수 있습니다.(스크린샷 이미지는 테스트를 위해 임시로 업로드한 파일입니다.)

이제 다음 명령어를 통해 커디 EC2의 s3 경로에 있는 이미지들을 커디 S3의 dev/ 경로에 업로드합니다.

aws s3 cp --recursive ./s3 s3://kerdy-dev/dev/

aws 콘솔에서 직접 확인해보면 성공적으로 이미지들이 모두 업로드된 것을 확인할 수 있습니다.

마무리

이렇게 해서 Source Account의 버킷 정책을 수정하지 않고, S3의 데이터를 이관할 수 있었습니다. 사이드 프로젝트를 하면서 서버를 이관하는 경우는 흔치 않은데, 오늘 정말 귀중한 경험을 한 것 같습니다. awscli라는 것도 처음 알게 됐고, S3의 버킷 정책과 IAM 역할을 수정하면서 AWS의 권한 정책에 대해 이전보다 더 이해할 수 있게 되었습니다.

Loading script...